1. Field of the Invention
This invention relates to computer software. More particularly, the invention relates to a system and method for creating a unification directory that unifies a plurality of file system directories.
2. Description of the Related Art
Computer systems generally store files on storage devices such as disk drives, where the files are managed by a file system. A file system typically includes a plurality of directories which are organized in a hierarchy. For example, the file system may have a root directory, the root directory may have sub-directories, and the sub-directories of the root directory may in turn have sub-directories, etc. Each file in the file system may be specified by a pathname that indicates the hierarchical sequence of directories that lead to the file. For example, a pathname such as “/dir1/dir2/filename.txt” indicates that a file named “filename.txt” is located in a directory named “dir2”. The “dir2” directory is in turn located in another directory named “dir1”, which is located in the root directory of the file system.
For each file, the file system stores a set of data blocks for the file (i.e., the actual data stored in the file by a user or application), as well as metadata for accessing and managing the file. For example, in Unix and Unix-derived file systems, file metadata is often stored in inodes. The inode for a file stores information about the file, such as the number of bytes in the file, protection and permission information, addresses of data blocks for the file's data, the dates and times when the file was created, last accessed, and modified, etc. The inode may also store information about the inode itself, such as an inode number that identifies the inode and possibly an inode version number.
Each directory in the file system may include a table of directory entries that maps the names of the files and sub-directories in that directory to their corresponding inodes (or other file metadata structures). In some file systems, a directory is implemented as a special type of file that simply lists the directory entries. For each file in the directory, the directory entry for the file simply maps the name of the file to the inode number of the file's inode. A software application may access a file if it knows the pathname of the file. For example, the sequence of directories leading to the file may be traversed until the file's directory is reached, and the directory entries of the directory may be consulted to map the name of the file to the file's corresponding inode. The file's inode may then be accessed, and the information stored therein may be used to access the file. For example, as noted above, the inode may store addresses of data blocks (e.g., data blocks on a disk drive or other storage device) that hold the file's data. Thus, the data blocks may be accessed, for example, to read data from the file or to append new data to the file.
FIG. 1 illustrates an example of a directory 2 specified by the pathname “/root/dir1”. The directory 2 includes files 4 named “Name_A”, “Name_B”, “Name_C”, “Name_D”, and “Name_E”. FIG. 2 illustrates a table of directory entries 15 for the “/root/dir1” directory 2. As discussed above, the table includes a respective directory entry for each of the files in the directory which maps the name 20 of the file to the inode number 21 of the inode for the file.
FIG. 3 illustrates the directory entry 15 for the file named “Name_A” in the “/root/dir1” directory. The directory entry 15 maps the name 20 of the file (i.e., “Name_A”) to an inode number 21, i.e., “12543” in this example. In other words, the inode having the inode number 12543 is the inode that corresponds to the file named “Name_A” and stores information about the file named “Name_A”.
FIG. 3 also illustrates the inode 160 having the inode number 12543, i.e., illustrates the inode 160 for the file named “Name_A”. The inode 160 includes information specifying various attributes of the file, such as the length (number of bytes) of the file, the file creation time, the file modification time, etc. The inode 160 also specifies that data for the file is located at a data block 25 having the data block number 34765. For example, the data block number 34765 may refer to a data block or address of a disk drive or other storage device. FIG. 3 also illustrates the data block 25 having the data block number 34765, where the data block 25 includes data for the file. The inode 160 may also include various other attributes not illustrated in FIG. 3. Also, the inode 160 may specify multiple data blocks for the file or may indirectly point to data for the file by pointing to other data block pointers which point to data for the file.
For some applications it is necessary to unify a group of directories into a single directory. Consider an application that normally accesses a hardware driver file in a particular operating system directory. If the application is executed on a virtual computer instead of a real computer then it may be necessary to use a special driver file instead of the normal hardware driver file.
Suppose that the normal hardware driver file is named “display.sys” and is located in a directory, e.g., “/t/drivers”. Suppose also that the special driver file has the same name as the normal hardware driver file and is located in another directory, e.g., “/v”. The functionality of replacing the normal hardware driver file with the special driver file can be transparently achieved by configuring a unification of the directories “/t/drivers” and “/v” such that the “/t/drivers” appears to contain not only its own files, but also the files of the “/v” directory. A unification file system can implement the unification such that application programs are unaware that some of the files that appear to be in the directory “/t/drivers” are actually located in the “/v” directory. For example, if the “/v” directory contains a file named “foo.sys” then an application may request to access the file using the pathname “/t/drivers/foo.sys”, and the unification file system will automatically intercept the request and redirect it to the “foo.sys” file in the “/v” directory. In the case of the special driver file, the “/t/drivers” directory already has a file named “display.sys”. The unification may be configured so that the “/v” directory is given priority over the “/t/drivers” directory. Thus, when the application requests the file “/t/drivers/display.sys”, the unification file system may intercept the request and redirect it to the “display.sys” file in the “/v” directory instead of the “display.sys” file in the “/t/drivers” directory.
Various systems known in the prior art enable a group of directories to be unified in the manner described above. For example, unification file systems (also called union file systems) may enable files and directories of separate file systems, known as branches, to be transparently overlaid, forming a single coherent file system. Contents of directories which have the same path within the merged branches will be seen together in a single merged directory, within the new, virtual file system. When mounting branches, the priority of one branch over the other is specified. Thus, when multiple branches contain a file with the same name, one gets priority over the others. Some application virtualization platforms also provide similar functionality enabling multiple directories to be unified, e.g., as in the virtual computer example discussed above.
Some prior art systems for unifying a group of directories operate to dynamically create a temporary merged view of the underlying directories in the group each time a merged view of the directories is needed. For example, each time a list of files in the merged directory needs to be obtained, these prior art systems may dynamically obtain a listing of the files in each of the individual directories in the group, and then merge the listings together. However, dynamically obtaining a merged listing in this manner is a relatively expensive operation to perform and may decrease the efficiency of the system.